Anomalies
NOTE: The Anomalies functionality is part of the SysTrack Intelligence Package. To access this functionality, you must purchase the Intelligence Package. Contact your Account team for more details.
This feature offers a machine-learning model that detects anomalies in a customer’s environment. By detecting issues early, customers can fix problems before they become widespread.
Anomalies Overview Page
Access the Anomalies feature in Prevent.
If there are no anomalies found, the History graph is blank. From the sensor drop down list, at the top right of the graph, select a sensor that is involved in the model to see its history. For a list of sensors that are analyzed by the model , see
Use the Manage Notification link to go to Sensor Notifications and configure notifications, including anomalies.
The Anomalies page includes three views:
- Active: Anomalies currently under investigation.
- Dismissed: Anomalies manually dismissed by users but still monitored by the model.
- Resolved: Anomalies that have been resolved either by system recovery or normalization of sensor data.
Active Anomalies
By default, the Anomalies page shows Active Anomalies.
An anomaly will be detected when one sensor is activated more than normal on a statistically significant number of systems.
Active anomalies display at the top of the screen. Each anomaly is represented by a card listing the anomaly name, sensor involved, systems impacted, and assignees. The information refreshes when you refresh the page.
By default, every anomaly starts with an ID. You can give the anomaly a friendly name, which displays at the top of the anomaly tile. To rename an anomaly, view the Anomalies Detail page. For more information, see Drill Into an Active Anomaly.
At the bottom right of the card, the initials of the user assigned to the anomaly display. When you hover over the initials, the user's full name displays. If there is no assignee, an exclamation point displays.
Dismissing and Reverting Anomalies
Dismiss an Anomaly
Users can dismiss anomalies that are not actionable. Dismissed anomalies:
-
Move to the Dismissed view.
-
Remain under model analysis until resolved.
-
Can be reverted to Active at any time.
To dismiss:
-
Open the anomaly detail page.
-
Click Dismiss Anomaly.
-
Optional: Add a note explaining the reason for dismissal.
-
Confirm the action.
Revert to Active
To revert a dismissed anomaly:
-
Open the anomaly in the Dismissed view.
-
Click Revert to Active.
There is no limit to the number of times an anomaly can be dismissed or reverted.
Dismissing an anomaly does not exclude it from model analysis. The anomaly continues to be monitored and evaluated until it is resolved.
Editing Dismissed Anomalies
Dismissed anomalies remain editable. You can:
-
Rename the anomaly (128-character limit).
-
Add or remove assignees (up to 5).
-
Provide thumbs up/down feedback.
-
Take action on systems via the systems grid.
Dismiss All
When there is more than one active anomaly in the Active view, a Dismiss All button appears. This allows users to dismiss multiple anomalies at once.
To dismiss all active anomalies:
-
Navigate to the Active view.
-
Click Dismiss All.
-
(Optional) Add a note explaining the reason for dismissal. The note will be added to all of the dismissed anomalies.
-
Confirm the action.
Notes in Anomalies
Users can add contextual notes to Anomalies that were Dismissed or Reverted back to Active:
-
Notes are text-only (no URLs or attachments).
-
Maximum length: 512 characters.
-
Notes can be added, edited, or deleted.
-
Notes are visible in the Activity Feed on the anomaly detail page.
Sort and Search for an Anomaly
To sort for an anomaly, click the drop-down list next to Sort. Most Recently Active (the default), sorts from newest to oldest. Number of Systems Involved sorts from the greatest number of systems to the least number of systems. You can use the sort function for both Active, Dismissed and Resolved Anomalies.
Use the search function to easily find an anomaly when there is a large number of anomalies in your environment.
You can search for an anomaly based on:
-
Anomaly name
-
Anomaly ID: When searching for an anomaly based on anomaly ID, it searches on the full anomaly ID, and not just the abbreviated ID shown on the tile.
-
Sensor names
-
Number of systems
-
Assignee names (not assignee initials)
When searching the numbers of systems, the search returns the full system count value (shown on hover of the abbreviated number on a tile) in addition to the abbreviated number shown on the tile.
The search box is available for both Active, Dismissed and Resolved anomalies.
History Graph
By default, the History graph shows the sensors that are involved in the active anomalies. There is a maximum of six sensors and instances that can be graphed at once. The graph displays the last 30 days of sensor history so that you can see the sensor behavior leading up to the anomaly. You can zoom in to specific days for more information.
NOTE: If there are more than six sensors involved in active anomalies, only those sensors from the most recently activated anomalies display.
To change which sensors display on the graph, use the sensor selection drop down list.
A red exclamation point displays on the graph at the time an anomaly is detected. When you hover over it, you can see the ID (or name if it has been renamed). Also, the corresponding anomaly tile is highlighted so you know which anomaly it pertains to if you have multiple active anomalies.
NOTE: The History Graph displays all anomalies by start date regardless of the sort option used.
Sensor Predictions
The Sensor Predictions tab displays the observed and normal range counts of a sensor or instance to clearly understand how the observed sensor counts trends over time and how that compares to the Anomalies model predictions.
When you select a sensor or instance from the dropdown list, the following data displays on the Sensor Predictions graph:
-
Observed count
-
Normal range (the range between upper and lower limits)
When you select a sensor line on the History graph, the Sensor Predictions graph opens to show that sensor graphed.
NOTE: The Sensors Prediction tab graphs one sensor at a time. This view helps visualize sensor behavior over time and supports analysis of individual sensor trends.
Drill Into an Active Anomaly
Select an anomaly card from the overview page to access more details about the anomaly.
This page shows the ID, the start date, and an option to rename the anomaly. Anomaly names must be unique and are limited to 128 characters.
Refresh the page to update information about the anomaly.
Add an Assignee to an anomaly so that users know who is investigating the anomaly. Only users with permissions to the Anomalies feature can be added as an assignee. There is a maximum of five assignees per anomaly. Assignees do not receive email notifications. To set up email notification recipients, see Sensor Notifications.
Provide Feedback
You can provide feedback on an anomaly to help improve the machine learning model.
In Prevent, when you select an active anomaly, you will see a question at the top of the screen.
When you click Yes or No, you will see a dialog box where you can share your feedback on the anomaly with the Lakeside Product team.
When you provide feedback, the dialog box will display again if you clear your browser cache or use a different browser.
Systems Table
The Systems table shows all systems affected by the anomaly. Use the drop down list to filter based on system status. By default, this table shows systems with the Active Status. If there are no systems with that status, the table defaults to All Statuses.
An anomalous system can have one of three statuses:
-
Active: A system, in its latest sensor results, was found to have the anomaly.
-
Monitoring: A system at one point in time was found to have the anomaly but in its latest sensor results the anomaly is not detected. This could be because it went offline (offline systems do not report sensor results), or perhaps you pushed a fix to a subset of systems that is resolving the anomaly. These systems will continue to be monitored until they are found to have the anomaly again or it has been resolved.
-
Recovered: A system is recovered if it is not found to have the anomaly for at least 72 hours.
The Systems Table is available for all anomaly states, including dismissed anomalies. Dismissing an anomaly does not remove system-level data. Users can continue to view and take action on affected systems from the anomaly view, even when the anomaly is in a dismissed state.
The number of systems in each state (All Statuses, Active, Monitoring, and Recovered) displays in the drop-down menu.
Double-click a system to view the system in Resolve or right-click to open the link in the same tab or in a new tab. The online column on the Systems table indicates whether the system is online.
NOTE: It is possible for a system to go offline between the time a user loads the Anomalies detail page and drills down into the system in Resolve.
Sensors Involved
This graph is a deeper view of the sensors involved in the anomaly itself. It shows the sensor behavior in 15-minute increments, starting at the time the anomaly was detected.
In general, the sensor count will be higher than the system count. The sensor count on this graph is the total number of times the sensor has activated in a 15-minute window. For example, three systems could have each had one sensor activate. Or, one system could have had a sensor activated three times within the 15 minutes window.
Systems Timeline
The Systems Timeline shows how the count of systems has changed over time. The timeline reflects systems as they are added to the anomaly and as they move to the Recovered status. In this timeline, systems with the Monitoring status are accounted for in the Active section.
Activity Feed
The Activity Feed shows the history of the anomaly, starting at the time it was detected. As more systems are found to have the anomaly, or as systems move to the recovered category, the FQDNs display in the Activity Feed. An entry is also added to the feed when an assignee is added
Users can also add contextual notes to dismissed anomalies and those reverted back to active. These notes appear in the Activity Feed and can be added, edited, or deleted.
NOTE: Any user can edit or delete a note, not just the user who originally added it.
When an anomaly is detected, and when more than 10 systems are added to the anomaly or moved to recovered, a Show Systems button displays in the Activity Feed. When you click Show Systems, it filters the Systems table to show those systems. Use the drop-down list at the top of the Systems table to make another selection to clear this filter.
Possible Events in the Activity Feed
|
Event |
Example |
|---|---|
|
Anomaly Detected |
|
| Systems Added: Less than Ten |
|
|
Systems Added: More than Ten |
|
|
Systems Moved to Recovered Status |
|
|
Assignee Added |
|
|
Anomaly Resolved |
|
| Anomaly Dismissed |
|
| Anomaly Reverted to Active |
|
|
Resource Consumption Error |
|
Resolved Anomalies
From the Overview page, select Resolved from the dropdown list to view historical anomaly data.
When you select Resolved, it shows all anomalies that were resolved within the past year. Dismissed anomalies that have been resolved are also visible and distinguishable by a DISMISSED banner. This indicates that the anomaly was dismissed before it naturally resolved.
Select an anomaly card to drill into details about resolved anomalies to see what happened.
For resolved anomalies:
-
You do not have edit access.
-
You cannot change the assignee or modify the name of the anomaly.
-
The Systems table shows all systems that were affected.
-
The Online Status column indicates the current status of each device.
How Anomalies Resolve
There are two possible ways for an anomaly to resolve:
-
When all systems in the anomaly have moved to the recovered category.
-
The count of all sensors involved in the anomaly returns to a normal range for the environment.
Configuring Minimum Thresholds for Detection
SysTrack allows administrators to define the minimum threshold required for an anomaly to be detected. This threshold can be set either as a number of systems or a percentage of the estate.
Default Behavior
When the Default checkbox is selected:
-
SysTrack automatically sets the threshold to the greater of:
-
30 systems, or
-
0.5% of the total estate
-
-
The UI will display the resulting number of systems based on this calculation.
Custom Threshold Configuration
Administrators can override the default anomaly detection threshold by specifying a custom value.
To configure a custom threshold:
-
Navigate to Configure.
-
On the Administration page, go to the Anomalies section
-
Deselect the Default checkbox and under Count, select either:
-
Number of Systems, or
-
Percent of Systems
-
-
Enter the desired value.
This custom value will apply to the detection of new anomaly events only. It does not affect anomalies that are already active.
IMPORTANT: Once the minimum threshold is changed, it may take up to 24 hours for the new setting to take full effect across the system.
Notifications
An email or webhook notification will be sent to a designated list of recipients when an anomaly is detected.
NOTE: You cannot customize the content of an anomaly notification.
-
To assign an anomaly notification, go to Configure > Sensor Configuration > Notifications.
-
Click Recipients and then Add New Recipient.
-
(Optional) Select an existing recipient. The Type must be user, Distribution List, or System.
-
Click Receive Anomaly Notifications to add them as an anomaly notification recipient.
User Notifications
-
In Recipient Type, click User.
-
Enter the First Name, Last Name and Work Email.
-
Click Receive Anomaly Notifications.
-
Click Add Recipient.
Distribution List Notifications
-
In Recipient Type, click Distribution List.
-
Enter Name and Email.
-
Click Receive Anomaly Notifications.
-
Click Add Recipient.
System Notifications for Email
-
In Recipient Type, click System.
-
Enter Name.
-
In Connection, select Email and then enter the email address.
-
Click Receive Anomaly Notifications.
-
Click Add Recipient.
System Notifications for Webhooks
-
In Recipient Type, click System.
-
Enter Name.
-
In Connection, select Webhook.
-
Select the Notification Type: Anomaly Notification.
-
Enter the URL from the third-party system that is receiving the webhook.
-
Select a request method. The POST and PUT settings will depend on the third-party you integrate with.
-
Select an authentication method and enter the details.
-
(Optional) Add a header.
-
Use the default webhook body template, or create a new one. The available variables can be selected from the dropdown.
-
Click Add Recipient.
Anomaly Notification Webhook Payload Variables
| Name | Variable | Description |
|---|---|---|
| Anomaly ID | @{anomalyId} | The ID (GUID) of the anomaly. |
| Activation Time | @{activationTime} |
The date and time the Anomaly was detected in UTC. (yyyy-mm-ddThh:mm:ss.ffffffffZ |
| Tenant ID | @{tenantId} | The ID (GUID) of the tenant. |
| Systems Impacted | @{totalSystemsAffected} | The total number of systems involved in the anomaly at the time of it occurring. |
| Sensor Name | @{sensorName} | Specific sensor involved in the anomaly. |
| Anomaly Prevent URL | @{anomalyDetailsURL} |
The URL that will take you to the Anomaly details page in Prevent. |
| Systems Affected Currently URL | @{systemsCurrentlyAffectedURL} | The URL to the API call to get the list of systems currently affected by this anomaly. |
| Systems Affected at Activation URL | @{systemsAtActivationURL} | The URL to the API call to get the list of systems affected at the start of the anomaly. |
Filter by Anomaly Notification Recipients
On the Recipients tab, click Show Only Anomaly Notification Recipients. The list displays only those users, systems distribution lists who are receiving anomaly notifications.
On This Page